Note: If you installed SCO OpenServer Release 5 from floppy you must order this package separately from SCO. There is a media charge.
One popular set of UNIX development tools is the GNU packages. The Free Software Foundation (FSF) has developed a well respected set of compilers, linkers, assemblers, debuggers, and other tools as part of the SCO, I have taken one popular distribution of several of the GNU packages and integrated then into the SCO OpenServer Release 5 environment. I chose the Cygnus release.
Cygnus provides commercial quality support for many GNU tools. Since they are the FSF chosen maintainers of many of the packages, they have in-house experts on these tools. Cygnus is a commercial business. While they do advance the state of free software, charging for support is their livlihood.
I have been working with Cygnus and the FSF to get the required changes integrated into the official versions of these packages.
These tools are not a complete replacement for the SCO OpenServer Development System. If you are in the business of providing commercial products for SCO systems, you really should have the SCO package. It includes the full documentation, the SCO debuggers (dbx, dbxtra, and the Motif dbXtra) plus the SCO Optimizing C Compiler that generates thoroughly impressive code.
Select "Install New" option from the "Software" menu.
Follow the prompts to steer custom toward the original media you used to install SCO OpenServer 5.
Select Application Development Libraries and
Linker
. Install it all. This will give you the
libraries, headers, and man pages.
gds.tar.gz.
You must extract these in a writeable directory with enough space. The
files total about 42 MB when uncompressed.
cd
Using the tools
The GNU documentation is provided, and will apply almost
wholescale to this project. The following exceptions are
noted. All apply to the compiler, gcc.
-B elf
instructs the compiler to emit ELF.
The default is to emit COFF.
-Ansi
uses ANSI headers and libraries
-Compat30
used ODT 3.0 compatible headers and libraries.
-Posix
uses POSIX headers and libraries.
-Xpg4
uses XPG4 headers and libraries.
-Xpg4plus
uses XPG4 headers and libraries, with chosen extensions fro the ODT 3.0 environment. This is the default.

Rebuilding from source
In any package of this flexibility, there are a number of ways
it can be configured. Some will surely look at my method and find it
obtuse. The major rationale of it is that it parallels the method I
use at my day job and that of Cygnus. Since I will typically build
about eight sets of compilers from the same source tree [ two are used
in this project ] having them each in separate directories really is a
necessity.
The master source is in /usr/skunk/src/Tools/gds/gds.tar.gz.
I create two directories. One is elf, one is coff. There is some
overlap between the two sets to allow independent builds. The ELF
release is the more capable of the two. For example, the 'nm' command
in the ELF tree knows about COFF, but the 'nm' in the COFF tree does
not know about ELF.
To make both COFF and ELF releases:
make all
To make the COFF release:
make coff
To make the ELF release:
make elf
It is important that the make install of the ELF tree be done after
that of the COFF release. While some things are redundant (i.e.,
'make' doesn't know anything about the object file format) the only
tools that know about both are those in the ELF tree.
The binaries are provided with no debugging, but are not stripped.
This is likely to be a problem only if you are debugging the tools
themselves. If this is the case, you know how to make your own set
with debugging and unstripped.
Also, to simplify the naming somewhat (and allow reasonable use of the '-b elf' flag), I suggest making /usr/local/lib/gcc-lib/elf a symlink to /usr/local/lib/gcc-lib/i486-unknown-sco3.2v5.0.0elf.

Bribing the Contributor:
Patches and enhancements are welcome.
Complaints about the GNU versions I used are not.
Suggestions are accepted.
Whining is not.
If you find this work useful, find a nice postcard of your hometown
and send it to:
Robert Lipe
102 Pebble Creek Road
Franklin, TN 37064 USA
Hopefully, this will help me judge if anyone appreciates this work
enough to continue to maintain it.
If you find it *really* useful, I wouldn't
decline a care package from a local microbrewery along with a short
description of the wares produced there. :-)

Known limitations
C++ is provided, but untested.
Compatibility with SCO supplied debuggers is untested. GDB
could probably be trained to play nice with these programs if it
doesn't already. Passing the -gstabs flag to gcc would probably
increase the chances of it working.

Without Whom Department
Of course, any project like this is the results of the work of many.
However, some in particular stand out.
Larry Philps larryp@sco.com twisted my arm into
doing this with one sentence. (grumble, grumble. Tell me I'm not
guru enough....) Larry also provided much testing, some
documentation, and many quick answers about the SCO provided tools
that we have to interface with.
John R. MacMillan john@sco.com was very patient
with my questions ranging from the undocumented to the blatantly
documented. He unraveled the mysteries of the .notes section and many
geeky details on the linker internals.
Many SCO employees that actively monitor Usenet including Bela Lubkin
and Dion Johnson for listening to the feedback about the need of
freely available libraries, headers, etc. and helping to make it
happen by passing that feedback on.
Of course, the GNU project must be thanked for providing us with such
a solid code base to work from. Support them any way you can!